Efficient key generator for distribution of sensitive material from mulitple application service providers to a secure element such as a universal integrated circuit card (uicc)

ABSTRACT

A method provides end-to-end security for transport of a profile to a target device (e.g., a mobile computing device) over at least one communications network that includes a plurality of nodes. In accordance with the method, the profile is encrypted for transport between the target device and an initial node of the network through which the profile is transported. The encryption is an end-to-end inner layer encryption performed prior to hop-to-hop encryption. The encrypting uses a public key of a public, private key pair. The private key is derivable from a seed securely provisioned in the target device using a public key algorithm. The encrypted profile is transmitted over the communications network to the target device.

RELATED APPLICATION

This application claims priority to provisional patent application Ser.No. 61/702,192, entitled “EFFICIENT KEY GENERATOR FOR DISTRIBUTION OFSENSITIVE MATERIAL TO MULTI-OWNER SECURE ELEMENTS”.

BACKGROUND

Current smart-card technologies are moving towards non-removableembedded smart cards for use in mobile computing devices, such as mobilephones, tablet computers, and automobile navigation systems. Recentexamples include embedded Universal Integrated Circuit Cards (UICC),which are used to host security-sensitive functions. Aside from smartcards, there is also a trend to use trusted environments to performfunctions similar to functions currently performed by smart cards.

Non-removable, embedded smart cards and trusted environments, however,often need data to be provided to them after being embedded. Because ofthis, embedded smart cards and trusted environments are provided withsensitive data remotely. Providing sensitive data remotely, however,suffers from various security risks, communication complexities, andaccountability uncertainties.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example environment in which techniques may beemployed that enable multiple profiles provided by multiple applicationservice providers to be securely transmitted to a target device.

FIG. 2 illustrates a simplified example of a packet that may be used totransmit the profile through the provisioning infrastructure shown inFIG. 1.

FIG. 3 illustrates one example of a key generation process that may beused to encrypt a profile using a key agreement exchange processperformed by the SM-DP shown in FIG. 1.

FIG. 4 illustrates one example of an inner layer decryption process thatmay be performed by a target device to obtain the decrypted profile.

FIG. 5 illustrates one example of a target device.

FIG. 6 shows one example of a computing device that may be employed as asource node and/or an intermediate node used in the provisioninginfrastructure of FIG. 1.

DETAILED DESCRIPTION

Application service providers such as a mobile network operator (MNO),for example, generally need to remotely provision sensitive data into asecure execution environment of a target device such as a mobilecomputing device. Since a target device may obtain services frommultiple application service providers, each of which may provision itsown secure data into its own secure domain of the secure executionenvironment, the number of different secure domains may become large.This can present a challenge when the amount of resources and securestorage space in the secure execution environment is limited.

As detailed below, techniques and arrangements are provided which allowmultiple application service providers to provision sensitive data,referred to herein as a profile, in a target device. A profile mayinclude, by way of example, security application algorithm codes, dataand cryptographic keys. Such provisioning may include the transport ofencrypted profiles through the network, decryption of encrypted profileswithin the secure execution environment, and installation of theprofiles within a secure storage for later execution within the secureexecution environment. Because profiles from multiple applicationservice providers are to be resident in the same secure executionenvironment, knowledge of each profile should be isolated within asecurity domain (e.g., a logical segmentation of hardware resourcessegmented and isolated from other segments by a firewall or the like)designated for the application service provider that is associated withthat profile.

The secure execution environment may include the above-noted embeddedUniversal Integrated Circuit Cards (UICC), other forms of embeddedchips, various trusted environments, or even movable or non-embeddedcards, such as SIM cards, or any of various devices or entities that maybenefit from receiving sensitive data securely.

The following discussion first describes an operating environment,followed by example methods for employing the techniques in theenvironment, and then proceeds with an example device for employing thetechniques.

Example Environment

FIG. 1 illustrates an example environment 100 in which techniques may beemployed that enable multiple profiles provided by multiple applicationservice providers to be securely transmitted. Environment 100 includes aprovisioning infrastructure that includes a source node 102, one or morewired and/or wireless communication networks 104, and intermediate nodes108, shown at nodes 108-1, 108-2, 108-3, and 108-4. The provisioninginfrastructure transmits the profiles to target device 106.

Generally, source node 102 is a source of sensitive data such as aprofile intended for the target device 106. In some cases, source node102 is associated with an ASP (e.g., a mobile network operator) insecure communication with a trusted one of the intermediate nodes 108(e.g., node 108-1), such as a trusted subscription manager capable ofend-to-end encryption of a packet having the sensitive data.

For purposes of illustration, source node 102 will be described as beingassociated with a mobile network operator, the trusted intermediate nodeis a subscription manager-data preparation (SM-DP), other intermediatenodes are non-serving subscription managers (SMs), and a lastintermediate node, which is trusted by the target device 106, is aserving subscription manager-secure routing (SM-SR). In addition, thesecure execution environment will often be described as a UICC. This isbut one example of many cases where the techniques described herein maybe employed. For instance, these same techniques may be used by a bankthat provisions smart cards for mobile banking, a utility company thatprovisions smart meters for tracking utility consumption, or a contentdelivery provider that provisions a target device such as a set-top boxto receive content from multiple content sources, where the content isprotected by a Digital Rights Management (DRM) mechanism or aConditional Access System (CAS).

Communication networks 104 can include one or multiple communicationnetworks, each represented by networks 104-1, 104-2, 104-3, 104-4, and104-5, though the term network may be a simple path between nodes orcomprise a complex combination of wired and/or wireless communicationchannels having multiple networks (e.g., cellular, wired, and wirelesslocal area). While not required, network 104-5 is illustrated as awireless network, as this last hop is often a wireless transmission.

The secure transport of the profile through the provisioninginfrastructure may require multiple layers of encryption. For instance,an inner layer encryption takes place at a subscription manager datapreparation node (SM-DP) to provide end-to-end (i.e, SM-DP to targetdevice) protection. An outer layer encryption may be performed overvarious hops (i.e., SM-SR) of the infrastructure. The outer layerencryption over each hop will be removed by the SM-SR at the end of eachhop. Over the last hop between the serving SM-SR and the UICC, the outerlayer encryption is removed by a general downloader function within theUICC, while leaving the inner layer encryption to take place in asecurity domain that is designated for a specific profile and iscryptographically separate. In this way the clear profile from oneapplication service provider is not exposed to any other parts of theUICC (e.g. a security domain belonging to another application serviceprovider).

Generally, target device 106 receives the profile in packets that aretransmitted through a node path 110. As part of the outer layerencryption process the packets have a cryptographic signature for eachnode along the required node path. FIG. 2 illustrates a packet 112 insimplified form, which has cryptographic signatures from each of theintermediate nodes 108 (“Int. #1 Sig.” etc.), as well as an end-to-endcryptographic signature (shown as “Source Sig.”), which is signed overthe payload (e.g., sensitive data), which may also include a profile.While each of the intermediate nodes 108 may cryptographically sign apacket as part of the outer layer encryption process, a required pathnode can be verified, in some embodiments, without a signature fromthose of the intermediate nodes that are trusted.

Inner Layer Encryption

As previously mentioned, a problem may arise when inner layer encryptionis employed to secure multiple profiles within a common secure executionenvironment. For purposes of illustration and not as a limitation on thesubject matter described herein, the secure execution environment willbe described as a Universal Integrated Circuit Card (UICC) that isembedded in a target device. Likewise, the ASP which provides theprofile will be referred to as an MNO.

A simply way to address this problem is to have a public, private keypair (denoted as PLK_UICC and PVK_UICC, respectively) for each UICC. TheSM_DP associated with each MNO will either encrypt the profile with thePLK_UICC directly or encrypt the profile with a symmetricprofile-encryption-key (PEK) and then in turn encrypt the PEK with thePLK_UICC.

A problem with this approach is scalability. Even if the same PEK isused for the entire UICC population for a given MNO (which presents asecurity risk), the SM-DP associated with the given ASP may have toencrypt profiles for millions of UICCs. Thus, the SM-DP would need tohave access to millions of PLK_UICCs prior to the provisioning process,which may create significant database problems, even if the keys couldbe addressed using the UICC identifier (UICC_ID). Furthermore, the UICCmanufacturer would have to ship lists of public keys (i.e., listsspecifying PLK_UICC) to each MNO that needs to provision the UICC. Thekey list may also need to be kept secure to avoid maliciousprovisioning.

This problem of scalability can be addressed if each MNO uses a globalkey pair for an entire population of UICCs such as all UICCs of a givenmodel. The public and private keys in this global key pair may bedenoted MNO_PLK_UICCM and MNO_PVK_UICCM, respectively. In this way eachMNO's SM-DP can use the same key to encrypt a profile (or a PEK) for allUICCs of the same model, but different MNOs will use different keypairs. This approach can significantly simplify the profile preparationprocess since a database search for individual UICC-unique public keys(PLKs) is not necessary.

However, this approach may create storage problems formemory-constrained UICCs, especially if RSA key pairs are used. A UICCpotentially may have to contain a large number of key pairs,particularly if it is going to be used in a geographic region with alarge number of MNOs such as in Western Europe, for example.Furthermore, if pre-loaded RSA key pairs are used for each MNO, new MNOsfor which an RSA key pair had not been pre-loaded in the UICC would beexcluded from serving the target device in which the UICC is employed.While it is possible to preload a number of RSA key pairs in UICCs andlater assign the key pairs to a new MNO as needed, ultimately thestorage space in the UICC would determine the maximum number ofoperators that can be supported.

Another alternative approach is to use public key algorithms that allowa private key to be generated as a random value. An example of such apublic key algorithm is Elliptic Curve Cryptography (ECC). In contrastto RSA key pairs, where the key generation process involves the searchfor prime numbers with specific properties, ECC private keys (PVK) onlyhave to be within a specific range and, once the ECC PVK and the ECCcurve are known, the ECC public key (PLK) can be generated simply byhaving knowledge of the PVK and the ECC curve.

To generate ECC private keys within the UICC, a private seed that isunique to each UICC can be loaded within each UICC. In someimplementations the seed can be generated by the UICC manufacturer andloaded into the UICC within the UICC manufacturing facility such thatonce it is loaded it cannot be extracted and will only be known to theUICC manufacturer and the secure execution engine within the UICC. Inone particular implementation a new ECC private key (MNO_ECC_PVKDEV) canbe calculated as follows using as input a key generation function (KGF)and an MNO identifier (MNO_ID):

-   -   MNO_ECC_PVKDEV=KGF(private_seed, MNO_ID)

As previously mentioned, the corresponding ECC public key can be createdfrom the ECC private key and the ECC curve.

In some cases, for a highly robust implementation a hardware key laddermay be implemented such that both the seed and the PVK cannot be exposedwithout hardware tampering. The KGF may be proprietary or awell-established function. For example, the KGF can be a standard MAC(Message Authentication Code) function such as HMAC-SHA1, HMAC-SHA256,AES-CMAC, and so on. The KGF should be chosen such that it generates akey of sufficient size which matches the Elliptic Curve parameters.

Since the UICC only needs to store the seed it is able to savesignificant storage space (in comparison to the amount of storage spaceneeded to store multiple RSA PVKs for multiple MNOs as well ascertificates for those MNOs). Using the seed and the MNO_ID, the UICC isable to generate the MNO_ECC_PVKDEV and then, using the ECC curve, theUICC is able to create the associated MNO_ECC_PLKDEV.

An MNO that intends to provision a population of UICCs with profilescontacts the UICC manufacturer or vendor for a list of key pairs that isspecific to that MNO. Accordingly, the UICC manufacturer or vendorcreates a private, public key pair (MNO_ECC_PVKDEV, MNO_ECC_PLKDEV)based on the private seeds and then sends the public key list (the listof MNO_ECC_PLKDEV) to the SM-DP associated with that MNO.

As an authentication measure, the list of public keys may be keptsecret. If the key list were public, any party could use a publicMNO_ECC_PLKDEV to encrypt an illegitimate profile and send it to a UICC.To avoid such an attack, the MNO SM-DP would have to sign the encryptedprofile. However, the verification of this signature would requireinstallation of MNO SM-DP certificates for every single MNO/SM-DP withinthe UICC, which would defeat the purpose of using ECC and private seedsfor storage space optimization. Accordingly, by maintaining the publickey list in secret the use of a signature can be avoided.

To be able to establish a profile encryption key (PEK) using ECC, a keyagreement exchange may take place between the MNO SM-DP and each UICC.One example of a key exchange algorithm that may be employed is aDiffie-Hellman exchange (ECDH) algorithm. However, to avoid the delayand network traffic associated with a Diffie-Hellman exchange, the keygeneration process shown in FIG. 3 may be used to encrypt a profileusing a key agreement exchange process performed by the MNO's SM-DP. Aspart of this process the SM-DP generates its own ECC private, public keypair (denoted MNO_ECC_PVKOP and MNO_ECC_PLKOP, respectively). This keypair may be unique for each UICC, a population of UICCs, or each ECDHprocess that is performed. The SM-DP will then use its own ECC privatekey (MNO_ECC_PVKOP) and the UICC public key (MNO_ECC_PLKDEV), which isprovided by the public key list from UICC manufacturer or vender, toperform a local ECDH key agreement 410 and create the PEK 430 from ashared ECDH secret 420. In some cases a key size reduction process 440may be performed when generating the PEK 430, depending on the key sizethat is needed to encrypt the profile. The SM-DP then uses the PEK toperform a symmetric key encryption process 450 to encrypt the profilefor the UICC. Finally, the encrypted profile, along with the MNO deviceidentifier (MNO_ID) and the MNO ECC public key (MNO_ECC_PLKOP) aredelivered to the target device of the provisioning infrastructure shownin FIG. 1.

Once the UICC receives the inner layer encrypted profile it performs adecryption process to remove the inner layer encryption, as illustratedin FIG. 4. As shown, the UICC uses its private seed and the MNOidentifier (MN_ID) to generate its own ECC private key (MNO_ECC_PVKDEV)using the pre-configured key generator function (KGF) 510. The UICC thencreates the PEK to perform decryption. To create the PEK, the UICC usesthe device ECC private key for this particular MNO (MNO_ECC_PVKDEV) andthe MNO ECC public key (MNO_ECC_PLKOP) to perform a local DH keyagreement process 520. As discussed above in connection with FIG. 3, theUICC can obtain the MNO ECC public key (MNO_ECC_PLKOP) from the MNOalong with the encrypted data, especially in cases where the MNO uses aunique public key for each UICC. Alternatively, the MNO ECC public keymay be obtained by the UICC through other means. For example, the MNOECC public key may be pre-provisioned in the UICC. One potentialdownside to this approach is that the local DH key agreement process 520may be considered as only half-authenticated since only theMNO_ECCPLKDEV is authenticated (since the UICC public key is provided aspart of a key list that is signed by the manufacturer), whileMNO_ECC_PLKOP is not authenticated by the UICC, unless the SM-DP uses asignature and an ECC certificate to prove the authenticity of theMNO_ECC_PLKOP.

The local ECDH key agreement process 520 creates the PEK 530 from ashared ECDH secret 540. In some cases a key size reduction process 550may be performed when generating the PEK 530, depending on the key sizethat is needed to encrypt the profile. The UICC then uses the PEK 530 toperform a symmetric key decryption process 560 to decrypt the profile,which is stored in secure storage device 570 associated with the UICC.

One advantage of the provisioning process described above is that apriori knowledge of the MNOs that may need to interact with the UICC isnot needed when the UICC is manufactured. This allows the businessecosystem within which the UICC is used to be extended in a flexiblemanner. In essence, there is practically no limit on the number of MNOsthe ecosystem can support. In practice the limit will be determined bythe number of key pairs that can be generated from the ECC curve, whichis a very large number compared to the possible number of MNOs.

A potential downside to this provisioning process, however, is that theUICC manufacturer needs to create a unique private seed for each UICCand then store the seeds in a seed list. Alternatively, all MNOs couldagree to use a common Root Certificate Authority (CA) and sign theirencrypted profiles using a certificate that chains to this common RootCA. While this would address the problem, in practice it can bedifficult to establish a common business and legal entity that wouldfunction as a Root Certificate Authority.

Instead of using a unique private seed for each UICC, another solutionis to use a global private seed for a population of UICC models and thenuse the UICC identifier (UICC_ID) in the calculation of the ECC privatekey for each UICC. That is, the private key MNO_ECC_PVKDEV for each UICCmay be generated using a key generation function (KGF) as follows:

-   -   MNO_ECC_PVKDEV=KGF(UICCM_private_seed, UICC_ID, MNO_ID)

A weakness of this alternative approach is that if the private_seed fora particular UICC model is exposed, then the entire population of UICCswill be compromised for all the MNOs involved.

It should be noted that the UICC does not need to calculate the publickey for the MNO, since it only needs to decrypt the profile encrypted byMNO's SM-DP. The public key list for each MNO may be signed by the UICCmanufacturer or vendor prior to shipment to the MNO's SM-DP. Inaddition, the public key list may need to be encrypted in order to keepit secret. One downside to this solution is that the UICC manufactureror vendor is fully trusted with both the private and public key pairsand thus plays a significant trusted role in the ecosystem. This is,however, also the case with existing UICC vendors.

The encryption algorithm described above employs Elliptic CurveCryptography (ECC) as the public key agreement algorithm which is usedto randomly generate a private key. Of course, other public keyagreement algorithm may be employed instead. For instance, in oneimplementation an alternative key agreement algorithm that may beemployed is the Diffie-Hellman algorithm where the private keyMNO_ECC_PVKDEV may be random and the public key is generated using:

-   -   MNO_ECC_PLKDEV=g^(MNO) ^(—) ^(ECC) ^(—) ^(PVKDEV)mod p        where g is called a generator and p is a large prime number,        typically at least 1024 bits long. This algorithm may be used        instead of the ECC algorithm described above in connection with        the encryption and decryption processes shown in FIGS. 3 and 4,        respectively.

It should also be noted that an MNO-specific boot code may be providedalong with, or as a part of, the profile. In either case the boot codemay be encrypted along with the profile itself. In such a case the UICCmay use the PEK to decrypt both the boot code and the profile, possiblyin the same step.

Replay Protection

In some cases it may be undesirable to allow the same encrypted profileto be retransmitted to the same target device without permission.However, there may be legitimate reasons to change the profile of atarget device and thus a cryptographic enforcement technique may beemployed to prevent retransmission of an old profile. One suchenforcement technique may employ a random value (i.e., a nonce) that isincluded in a message sent to the MNO by the target device requesting aprofile. The reply to the target device should include both theencrypted profile and the random value encrypted together with thatprofile. When the target device later decrypts the profile, it verifiesthat the random value matches the value included in the request message.If there is no match, it disregards the profile.

This cryptographic enforcement technique requires two-way communicationbetween the target device and the MNO. However, some target devices mayonly be capable of receiving a broadcast or a multicast and have no wayto send a request to the MNO. In this case, the MNO can include either asequence number or a timestamp within the encrypted profile. A targetdevice can persistently store this value and ensure that each successiveprofile update contains either a nonce or a timestamp that is greaterthan the previously received value.

Example Target Device

FIG. 5 illustrates one example of target device 106. Target device 106can be one or a combination of various devices, here illustrated withsix examples: a smartphone 106-1, a laptop computer 106-2, a television106-3, a desktop computer 106-4, and a tablet computer 106-5, thoughother computing devices and systems, such as netbooks, car navigationsystems, and servers may also be used.

Target device 106 includes a processor 602 for carrying out processingfunctions associated with one or more of components and functionsdescribed herein. Processor 602 can include a single or multiple set ofprocessors or multi-core processors. Moreover, processor 602 can beimplemented as an integrated processing system and/or a distributedprocessing system. Furthermore, processor 602 may house, execute, and/orprocess instructions related to reading and writing information to andfrom the target device 106 and/or the components contained therein. Forexample, in an aspect, processor 602 may generate and send instructionsto the UICC 614, cache 620, or memory 604 in the target device 106 tocause a cache to be written to or updated with information that has beenread from the UICC 614. Moreover, processor 602 may generate and sendcommands to a power management component on the target device.

Target device 106 further includes a memory 604, such as acomputer-readable storage medium for storing data used herein and/orlocal versions of applications being executed by processor 602. Memory604 can include any type of memory usable by a computer, such as randomaccess memory (RAM), read only memory (ROM), tapes, magnetic discs,optical discs, volatile memory, non-volatile memory, and any combinationthereof.

Further, target device 106 includes a communications component 606 thatprovides for establishing and maintaining communications with one ormore parties utilizing hardware, software, and services as describedherein. Communications component 606 may carry communications betweencomponents on target device 106, as well as between target device 106and external devices, such as devices located across a communicationsnetwork and/or devices serially or locally connected to target device106. For example, communications component 606 may include one or morebuses, and may further include transmit chain components and receivechain components associated with a transmitter and receiver,respectively, operable for interfacing with external devices.

Additionally, target device 106 may include a data store 608, which canbe any suitable combination of hardware and/or software, that providesfor mass storage of information, databases, and programs employed inconnection with aspects described herein. For example, data store 608may be a data repository for applications not currently being executedby processor 602.

Target device 106 may additionally include a user interface component610 operable to receive inputs from a user of target device 106, andfurther operable to generate outputs for presentation to the user. Userinterface component 610 may include one or more input devices, includingbut not limited to a keyboard, a number pad, a mouse, a touch-sensitivedisplay, a navigation key, a function key, a microphone, a voicerecognition component, any other mechanism capable of receiving an inputfrom a user, or any combination thereof. Further, user interfacecomponent 610 may include one or more output devices, including but notlimited to a display, a speaker, a haptic feedback mechanism, a printer,any other mechanism capable of presenting an output to a user, or anycombination thereof.

Target device 106 also includes a UICC 614, which may containsubscription, connection, or other information related to wirelesscommunication with a wireless network. In some examples, UICC 614 may beremovable, meaning that it may be detached from the target device 106 ifremoval is needed. In a further aspect, UICC 614 may store personal datafor a user. Additionally, the UICC may contain a subscriber identitymodule (SIM) application, a universal subscriber identity module (USIM),and/or a CDMA subscriber identity module (CSIM) application for networkauthentication purposes. In some aspects, UICC 614 may contain aremovable user identity module (R-UIM), or may itself be referred to asan R-UIM. In some examples, UICC 614 may include an internal centralprocessing unit (CPU), random access memory (RAM), read-only memory(ROM), electrically-erasable programmable read only memory (EEPROM),other non-volatile or volatile memory, and/or input/output circuitry.Additionally, the UICC may contain information related to radio accessnetworks utilizing several access technologies and/or communicationprotocols, such as, but not limited to, Global System for MobileCommunication (GSM), Enhanced Data Rates for GSM Evolution (EDGE),Universal Mobile Telecommunications System (UMTS), High Speed PacketAccess (HSPA), Long Term Evolution (LTE), LTE Advanced, or any otherhigh-speed data packet network access technology, including those accesstechnologies that are part of the 4G access technology family.

Target device 106 may include a power management component 612 forswitching power to UICC 514 on and off. Power management component 612may receive instructions for switching power to the UICC 614 on and offfrom processor 602 or any other component in target device 106 and/orcomponents external to target device 106, such as network components.

Target device 106 may include a nonvolatile memory (NV) component 618.In an aspect, the NV may contain subscription, connection, or anyinformation related to establishing a connection with a wireless networkor authenticating a user to such a network. By non-limiting example,such a wireless network may utilize an access technology and/orcommunication protocol or standard such as, but not limited to, CDMA20001× (IS-2000), 1×, 1×RTT, CDMA2000, and/or 1×EV-DO (Evolution-DataOptimized), also known as EV-DO or EV, or any other access technologythat is part of the 3G access technology family.

Target device 106 may contain a cache 620, which may store informationrecently read from UICC 614. Cache 620 may include memory for storingsuch information, which may any type of memory usable by a computer,such as RAM, ROM, EEPROM, tapes, magnetic discs, optical discs, volatilememory, a general non-volatile memory. In an aspect, cache 620 mayinclude NV 618, and therefore may store contain subscription,connection, or any information related to establishing a connection witha wireless network or authenticating a user to such a network. Again, bynon-limiting example, such a wireless network may utilize an accesstechnology and/or communication protocol or standard such as, but notlimited to, CDMA2000 1× (IS-2000), 1×, 1×RTT, CDMA2000, and/or 1×EV-DO(Evolution-Data Optimized), also known as EV-DO or EV, or any otheraccess technology that is part of the 3G access technology family.Additionally, because it may contain subscription information read fromUICC 614 in the past, cache 620 may include information stored on theUICC 614, such as, but not limited to information related to radioaccess networks utilizing several access technologies and/orcommunication protocols, such as, but not limited to, Global System forMobile Communication (GSM), Enhanced Data Rates for GSM Evolution(EDGE), Universal Mobile Telecommunications System (UMTS), High SpeedPacket Access (HSPA), Long Term Evolution (LTE), LTE Advanced, or anyother high-speed data packet network access technology, including thoseaccess technologies that are part of the 4G access technology family.

As previously mentioned, instead of a UICC, the target device 106 mayinclude other forms of embedded chips, various trusted environments, oreven movable or non-embedded cards, such as SIM cards.

Example Node

FIG. 6 shows one example of a computing device 800 that may be employedas a node (e.g., source node 102 and/or intermediate nodes 108 ofFIG. 1) in the provisioning infrastructure of FIG. 1. Computing device800 can be integrated with electronic circuitry, a microprocessor,memory, input-output (I/O) logic control, communication interfaces andcomponents, other hardware, firmware, and/or software needed to run anentire device. Computing device 800 can also include an integrated databus (not shown) that couples the various components of the computingdevice for data communication between the components.

Computing device 800 includes various components such as an input-output(I/O) logic control 802, microprocessor(s) 804 (e.g., a microcontrolleror digital signal processor), operating system 808 and communicationsinterface 812. Computing device 800 also includes a memory 806, whichcan be any type of random access memory (RAM), a low-latency nonvolatilememory (e.g., flash memory), read only memory (ROM), and/or othersuitable electronic data storage. Memory 806 includes or has access toencryption module 810, which may be used to perform inner and/or outerencryption.

Computing device 800 can also include various firmware and/or software,such as an operating system 808, which, along with other components, canbe computer-executable instructions maintained by memory 806 andexecuted by microprocessor 804. Computing device 800 can also includeother various communication interfaces 810 and components, wireless LAN(WLAN) or wireless PAN (WPAN) components, other hardware, firmware,and/or software.

Other example capabilities and functions of these modules and componentsare described with reference to components shown in FIGS. 1, 2, and 3.These modules and components, either independently or in combinationwith other modules or components, can be implemented ascomputer-executable instructions maintained by memory 806 and executedby microprocessor 804 to implement various embodiments and/or featuresdescribed herein. Alternatively or additionally, any or all of thesecomponents can be implemented as hardware, firmware, fixed logiccircuitry, or any combination thereof that is implemented in connectionwith the I/O logic control 802 and/or other signal processing andcontrol circuits of example device 800. Furthermore, some of thesecomponents may act separate from device 800.

Although the invention has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the invention defined in the appended claims is not necessarilylimited to the specific features or acts described. Rather, the specificfeatures and acts are disclosed as example forms of implementing theclaimed invention.

1. A method for providing end-to-end security for transport of a profileto a target device over at least one communications network thatincludes a plurality of nodes, the method comprising: encrypting theprofile between the target device and an initial node of the networkthrough which the profile is transported, the encryption being anend-to-end inner layer encryption performed prior to hop-to-hopencryption, the encrypting using a public key of a public, private keypair, the private key being derivable from a seed securely provisionedin the target device using a public key algorithm; and causing theencrypted profile to be transmitted over the at least one communicationsnetwork to the target device.
 2. The method of claim 1 wherein the seedis unique to a secure element located in the target device.
 3. Themethod of claim 1 wherein the public key algorithm is based on EllipticCurve Cryptography (ECC), the public key being derivable from theprivate key and an ECC curve.
 4. The method of claim 2 wherein theprivate key is derivable from the seed and an identifier associated witha manufacturer or vendor of the secure element.
 5. The method of claim 1wherein the seed is common to particular population of secure elements.6. The method of claim 3 wherein the public key algorithm is implementedusing hardware.
 7. The method of claim 4 further comprising maintainingin secret a list of public keys that includes the public key of thepublic, private key pair, the list of public keys being received by aservice provider delivering at least one service to a plurality oftarget devices in which a plurality of secure elements are respectivelylocated, the list of public keys being received from the manufacturer orvendor of the plurality of secure elements.
 8. The method of claim 7wherein the list of public keys is digitally signed by the manufactureror vendor.
 9. The method of claim 1 further comprising: generating anECC key pair associated with a service provider delivering at least oneservice to the target device; using an ECC private key in the ECC keypair and the public key of the public, private key pair to perform alocal Diffie-Hellman (DH) exchange to create a profile encryption keythat is used to encrypt the profile.
 10. The method of claim 9 whereinthe ECC key pair is unique to a particular population of secure elementsrespectively located in a population of target devices.
 11. The methodof claim 9 wherein the ECC public key in the ECC key pair ispre-provisioned in the target device.
 12. The method of claim 9 whereinthe ECC public key in the ECC key pair is transmitted to the targetdevice along with the encrypted profile.
 13. The method of claim 1wherein the public key algorithm is based on a DH algorithm.
 14. Themethod of claim 1 further comprising: receiving a request for theprofile from the target device, the request including a nonce;encrypting the nonce with the profile; and causing the encrypted profileand the encrypted nonce to be transmitted over the at least onecommunications network to the target device.
 15. The method of claim 1wherein the encrypted profile includes a timestamp or a sequence number.16. The method of claim 1 wherein the profile is encrypted by a mobilenetwork provider and the seed is located in a secure element in thetarget device.
 17. The method of claim 16 wherein the secure element isa Universal Integrated Circuit Card (UICC).
 18. A computer readablestorage medium encoded with computer executable instructions which, whenexecuted by a processor, performs a method for decrypting a profiletransmitted to a target device in a secure manner by a service providerover a communications network, comprising: receiving an encryptedrendition of the profile over the communications network; accessing aseed securely provisioned in the target device; deriving a first privatekey of a first public, private key pair from the seed; obtaining asecond public key in a second public, private key pair associated withthe service provider; using the second public key and the first privatekey derived from the seed to perform a local DH exchange to create asymmetric key; and decrypting the encrypted rendition of the profileusing the symmetric key.
 19. The computer readable storage medium ofclaim 18 wherein the second public, private key pair is generated usingan ECC algorithm.
 20. The computer readable storage medium of claim 18further comprising obtaining the second public key from the serviceprovider over the communications network.
 21. The computer readablestorage medium of claim 18 wherein the seed is unique to a secureelement located in the target device.
 22. The computer readable storagemedium of claim 18 wherein the seed is common to a particular populationof secure elements respectively located in a population of targetdevices.
 23. The computer readable storage medium of claim 22 furthercomprising deriving the first private key of the first public, privatekey pair using the seed and an identifier associated with a manufactureror vendor of the secure elements.
 24. The computer readable storagemedium of claim 22 further comprising deriving the first private key ofthe first public private key pair using the seed, a first identifierassociated with a manufacturer or vendor of the secure elements and asecond identifier associated with the secure element in the targetdevice.